Developer CD Series 1993…ch: Other People's Memory/ADC Developer CD (1993-03) (''Other People's Memory'')_iso/Dev.CD Mar 93.iso/Development Platforms/CSMP Digests/csmp-v1-017.txt

Text File | 1992-11-18 | 68.9 KB | 1,652 lines | [TEXT/MPS ]

C.S.M.P. Digest             Sun, 15 Mar 92       Volume 1 : Issue 17

Today's Topics:

    Given a file's vRefNum how do you get the complete path?
    getting vRefNumber???
    StandardPutFile


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu (try skinner.cs.uoregon.edu if that doesn't work).  This is also the home
of the comp.sys.mac.programmer Frequently Asked Questions list.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (David Dantowitz)
Subject: Given a file's vRefNum how do you get the complete path?
Date: 27 Jan 92 19:09:40 GMT
Organization: UCLA Computer Science Department


How does one get the full path for a file after selection with SFGetFile?

--
David Dantowitz
[e-mail]

Singing Barbershop when I'm not computing...



- -------------------------

From: [e-mail] (Kent P Miller)
Subject:  Given a file's vRefNum how do you get the complete path?
Organization: Engineering Computer Network, University of Oklahoma, Norman, OK
Date: Tue, 28 Jan 1992 04:44:03 GMT

In article <[e-mail]> [e-mail] (David Dantowitz) writes:
>
>How does one get the full path for a file after selection with SFGetFile?
Here's the code I copied out of the UMPG (works everytime for me):
(pass the fname part of the sfreply as the first parameter and the vrefnum
of the sfreply as the second parameter)

  function GetFullPath (x: str255; y: integer): str255;
   var
    tempName, thePath, comppath: Str255;
    vParams: CInfoPBRec;
    theError: OSerr;
    i: integer;
  begin
   thePath := '';
   tempName := '';
   with vParams do
    begin
     ioCompletion := nil;
     ioNamePtr := @tempName;
     ioVRefNum := y;
     ioFDirIndex := -1;
     ioDrDirID := 0;
     repeat
      theError := PBGetCatInfo(@vParams, FALSE);
      if (theError = noErr) then
       begin
       ioDRDirID := ioDRParID;
       thePath := concat(tempName, ':', thePath);
       tempName := '';
       end;
     until (theError <> noErr);
     tempName := concat(thePath, x);
     GetFullPath := tempName;
    end;
  end;


--
- ---------------------
Kent Miller
[e-mail]
Bitnet -> KENT@uokucsvx



- -------------------------

From: [e-mail] (Keith Rollin)
Subject:  Given a file's vRefNum how do you get the complete path?
Date: 28 Jan 92 23:31:54 GMT
Organization: Apple Computer Inc., Cupertino, CA

In article <[e-mail]> [e-mail] (David Dantowitz) writes:
>
>How does one get the full path for a file after selection with SFGetFile?

One looks at DTS sample code #18, or Technote #238, both available on
ftp.apple.com and from APDA, as well as many other ftp sites and
BBS's.

Of course, one must make sure that one is doing this for the right
reason.  The only reason I can think of to create a full pathname is
for display purposes (like MPW does in its menus and window titles, or
Standard File does in its popup menu). "UNIX port" is _NOT_ a good
reason.

--
- ----------------------------------------------------------------------------
Keith Rollin           ---            <Taligent .signature under construction>
Disclaimer: Pretty soon, I really _won't_ be speaking for Apple...



- -------------------------

From: [e-mail] (Keith Rollin)
Subject:  Given a file's vRefNum how do you get the complete path?
Date: 28 Jan 92 23:31:54 GMT
Organization: Apple Computer Inc., Cupertino, CA

In article <[e-mail]> [e-mail] (David Dantowitz) writes:
>
>How does one get the full path for a file after selection with SFGetFile?

One looks at DTS sample code #18, or Technote #238, both available on
ftp.apple.com and from APDA, as well as many other ftp sites and
BBS's.

Of course, one must make sure that one is doing this for the right
reason.  The only reason I can think of to create a full pathname is
for display purposes (like MPW does in its menus and window titles, or
Standard File does in its popup menu). "UNIX port" is _NOT_ a good
reason.

--
- ----------------------------------------------------------------------------
Keith Rollin           ---            <Taligent .signature under construction>
Disclaimer: Pretty soon, I really _won't_ be speaking for Apple...



---------------------------

From: Wade Williams
Subject: getting vRefNumber???
Date: 27 Jan 92 20:43:50 GMT
Organization: Auburn University

Can anyone tell me..given a volume's name, how can I obtain its reference
number?

Would I have to obtain the names of all mounted volumes, then compare them?

Thanks.

Wade



- -------------------------

From: [e-mail] (JohnC)
Subject:  getting vRefNumber???
Date: 28 Jan 92 00:27:14 GMT
Organization: The Royal Society for Putting Things on Top of Other Things

In article <[e-mail]> Wade Williams writes:
>Can anyone tell me..given a volume's name, how can I obtain its reference
>number?

Here's the code I use:

 CONST
  SYNC=false;
  invalidVRefNum = $8000;

 TYPE
  Str31=STRING[31]; {for HFS file/directory names}


 FUNCTION VRefFromName (vName: Str31; VAR vRef: integer): OSErr;
  VAR
   pb: ParamBlockRec;
 BEGIN
  vName := concat(vName, ':');  {crucial -- will fail if volume is not HFS}
  pb.ioNamePtr := @vName;
  pb.ioVRefNum := invalidVRefNum; {ensures OS will _only_ use the name}
  pb.ioVolIndex := -1; {ensures OS will use name at all}
  VRefFromName := PBGetVInfo(@pb, SYNC);
  vRef := pb.ioVRefNum;
 END; { FUNCTION VRefFromName }

 FUNCTION VNameFromRef (vRef: integer; VAR vName: Str31): OSErr;
  VAR
   pb: ParamBlockRec;
 BEGIN
  vName := '';
  pb.ioNamePtr := @vName;
  pb.ioVRefNum := vRef;
  pb.ioVolIndex := 0; {ensures OS will _only_ use vRef}
  VNameFromRef := PBGetVInfo(@pb, SYNC);
 END; { FUNCTION VNameFromRef }



- -------------------------

From: [e-mail] (Peter N Lewis)
Subject:  getting vRefNumber???
Date: 28 Jan 92 02:03:14 GMT
Organization: NCRPDA, Curtin University

In article <[e-mail]>, Wade Williams writes:
>
> Can anyone tell me..given a volume's name, how can I obtain its reference
> number?

I would have replied by mail, but your From address was non-existant.

Anyway, you use PBGetVInfo, and the trick is (there is always a secret
trick when dealing with the file manager :-) to make sure the volume
name you give it has a colon at the end of it:

function GetVolInfo (var name: str63; var vrn: integer; index: integer; var CrDate: longInt): OSErr;
  var
  pb: paramBlockRec;
  oe: OSErr;
begin
  with pb do begin
  if (name <> '') & (name[length(name)] <> ':') then
    name := concat(name, ':'); { The volume name must end in a colon }
  pb.ioNamePtr := @name;
  ioVRefNum := vrn;
  ioVolIndex := index;
  oe := PBGetVInfo(@pb, false);
  if oe = noErr then begin
    vrn := ioVRefNum;
    CrDate := ioVCrDate;
  end;
  GetVolInfo := oe;
end;

HTH,
   Peter.

______________________________________________________________________
Peter N Lewis, NCRPDA, Curtin University      [e-mail]
GPO Box U1987, Perth WA 6001, AUSTRALIA            FAX: [phone]



- -------------------------

From: [e-mail] (Kent P Miller)
Subject:  getting vRefNumber???
Date: 28 Jan 92 04:56:26 GMT
Organization: Engineering Computer Network, University of Oklahoma, Norman, OK

>Can anyone tell me..given a volume's name, how can I obtain its reference
>number?
>
The variable pb would be a parmBlkPtr.

  pb := parmblkptr(newptr(sizeof(ParamBlockRec)));
  pb^.ioNamePtr := @volname;
  pb^.ioVRefNum := 0;
  pb^.ioVolIndex := -1;
  theerr := PBGetVInfo(pb, false);
pb^.ioVrefNum will contain the vrefnum of the volume name specified in
volname.

Kent Miller

--
- ---------------------
Kent Miller
[e-mail]
Bitnet -> KENT@uokucsvx



- -------------------------

From: [e-mail] (Keith Rollin)
Subject:  getting vRefNumber???
Date: 28 Jan 92 23:45:09 GMT
Organization: Apple Computer Inc., Cupertino, CA

In article <[e-mail]> [e-mail] (Peter N Lewis) writes:
>In article <[e-mail]>, Wade Williams writes:
>>
>> Can anyone tell me..given a volume's name, how can I obtain its reference
>> number?
>
>I would have replied by mail, but your From address was non-existant.
>
>Anyway, you use PBGetVInfo, and the trick is (there is always a secret
>trick when dealing with the file manager :-) to make sure the volume
>name you give it has a colon at the end of it:

    [ sample code removed ]

Depending on your needs, you may want to take a different approach from
that shown in the sample code I removed. For instance, of you want to
save a reference to a specific volume in a preferences file, you should
save the volume's name and creation date. This allows you to
differentiate between different volumes with the same name (this
happens a lot if you have a bunch of floppies, all with the name
'Untitled'). To find the matching volume, I walk the list of mounted
volumes, comparing names and creation dates:

    index = 0;
    pb.volumeParam.ioNamePtr = volName;
    do {
        pb.volumeParam.ioVolIndex = ++index;
        err = PBGetVInfoSync(&pb);
        if (err == noErr) {
            if ((**entry).creationDate == pb.volumeParam.ioVCrDate
              && !PLstrcompare((StringPtr)volName, (StringPtr)(**entry).name)) {
                (**entry).vRefNum = pb.volumeParam.ioVRefNum;
                break;
            }
        }
    } while (err == noErr);

Here, "entry" is a handle to a struct that contains the creation date and
name of the volume I'm interested in. It also has a vRefNum field that
gets filled in by the above procedure.

(How many people here are happy that "entry" is no longer a reserved C
word? Raise your mice!)

--
- ----------------------------------------------------------------------------
Keith Rollin           ---            <Taligent .signature under construction>
Disclaimer: Pretty soon, I really _won't_ be speaking for Apple...



- -------------------------

From: [e-mail] (Keith Rollin)
Subject:  getting vRefNumber???
Date: 28 Jan 92 23:45:09 GMT
Organization: Apple Computer Inc., Cupertino, CA

In article <[e-mail]> [e-mail] (Peter N Lewis) writes:
>In article <[e-mail]>, Wade Williams writes:
>>
>> Can anyone tell me..given a volume's name, how can I obtain its reference
>> number?
>
>I would have replied by mail, but your From address was non-existant.
>
>Anyway, you use PBGetVInfo, and the trick is (there is always a secret
>trick when dealing with the file manager :-) to make sure the volume
>name you give it has a colon at the end of it:

    [ sample code removed ]

Depending on your needs, you may want to take a different approach from
that shown in the sample code I removed. For instance, of you want to
save a reference to a specific volume in a preferences file, you should
save the volume's name and creation date. This allows you to
differentiate between different volumes with the same name (this
happens a lot if you have a bunch of floppies, all with the name
'Untitled'). To find the matching volume, I walk the list of mounted
volumes, comparing names and creation dates:

    index = 0;
    pb.volumeParam.ioNamePtr = volName;
    do {
        pb.volumeParam.ioVolIndex = ++index;
        err = PBGetVInfoSync(&pb);
        if (err == noErr) {
            if ((**entry).creationDate == pb.volumeParam.ioVCrDate
              && !PLstrcompare((StringPtr)volName, (StringPtr)(**entry).name)) {
                (**entry).vRefNum = pb.volumeParam.ioVRefNum;
                break;
            }
        }
    } while (err == noErr);

Here, "entry" is a handle to a struct that contains the creation date and
name of the volume I'm interested in. It also has a vRefNum field that
gets filled in by the above procedure.

(How many people here are happy that "entry" is no longer a reserved C
word? Raise your mice!)

--
- ----------------------------------------------------------------------------
Keith Rollin           ---            <Taligent .signature under construction>
Disclaimer: Pretty soon, I really _won't_ be speaking for Apple...



---------------------------

From: [e-mail] (Gerry Allwein)
Subject: StandardPutFile
Organization: Center for Innovative Computing Applications (CICA), Indiana University
Date:  7 Feb 92 15:41:10 GMT

I've been attempting to StandardPutFile and find that it the vRefNum field
of the sfFile for the reply is always set to -1, not at all what the old
SFPPutFile returns for the vRefNum. This is system 7.0, on a Mac ci. Anyone
know how to fix this? Is it a bug in StandardPutFile?

Gerry




- -------------------------

From: [e-mail] (Daniel Norman Johnson)
Subject:  StandardPutFile
Organization: Information Technology Services, Rennselaer Polytechnic Institute.
Date: Sat, 8 Feb 1992 03:32:39 GMT

> I've been attempting to StandardPutFile and find that it the vRefNum field
> of the sfFile for the reply is always set to -1, not at all what the old
> SFPPutFile returns for the vRefNum. This is system 7.0, on a Mac ci. Anyone
> know how to fix this? Is it a bug in StandardPutFile?

> Gerry

Yes, I just had to figure that out. Its really supposed to do that.

The vRefNum you get from StandardPutFile and StandardGetFile is *REALLY*
a volume reference number, *NOT* a working directory reference number.
(read Inside Macintosh Volume 4 for what a Working Directory is, if you
do not know)

I know, they are always called vRefNums. Usually they do not mean it. What
you need to do is use the OpenWD (open working directory) command System 7.0
provides to make that into a Working Directory Refnum; Do not worry about
the fact that this command is not availiable in system 6.0, because FileSpecs
and such things don't even happen. So just use OpenWD and don't use PBOpenWD (
or whatever the low-level equivalent is);

You'll need to use the parent directory id for this also.

For that other parameter (PBprocID or something like that?) just pass 0;
that way if you need to access the same working directory more than once it'll
just give you the same Working Directory. I don't know if you are supposed
to close the WD, does anybody here?

This is necessary if you ever have to access a file which is given by
a file-spec with old routines. However, if you are using the new FileSpec
routines, you can just pass the FileSpec to them. If you are writing
System-7 dependant stuff, I recommend this because you do not have to deal
with the Poor Man's Search Path. But that doesn't make a difference with
StandardPutFile/GetFile.



- -------------------------

From: [e-mail] (JohnC)
Subject: about working directories (was Re: StandardPutFile)
Date: 8 Feb 92 20:07:12 GMT
Organization: The Royal Society for Putting Things on Top of Other Things

In article <[e-mail]> [e-mail] writes:
>The vRefNum you get from StandardPutFile and StandardGetFile is *REALLY*
>a volume reference number, *NOT* a working directory reference number.
>(read Inside Macintosh Volume 4 for what a Working Directory is, if you
>do not know)
>
>I know, they are always called vRefNums. Usually they do not mean it. What
>you need to do is use the OpenWD (open working directory) command System 7.0
>provides to make that into a Working Directory Refnum; Do not worry about
>the fact that this command is not availiable in system 6.0, because FileSpecs
>and such things don't even happen. So just use OpenWD and don't use PBOpenWD (
>or whatever the low-level equivalent is);

The old Standard File routines return a real vRefNum if the chosen file is
in the root directory, else they return a wdRefNum that specifies the directory
that contains the file.  _OpenWD (and all the other high-level HFS calls)
_are_ available under system 6, since they are all implemented by glue code
in libraries.  The _only_ working directory call that you should _ever_
make is _GetWDInfo (or _PBGetWDInfo, of course).

>You'll need to use the parent directory id for this also.
>
>For that other parameter (PBprocID or something like that?) just pass 0;
>that way if you need to access the same working directory more than once it'll
>just give you the same Working Directory. I don't know if you are supposed
>to close the WD, does anybody here?

NoNoNoNo.  Working directories are a compatibility hack for applications
that don't know about HFS and directory IDs.  You never have to make your
own.  When using the old Standard File routines, simply pass the contents
of the vRefNum field in the reply record to _GetWDInfo.  This routine will
return the corresponding _real_ volume refNum and a directoryID.  Once you
have these, you need not consider the wdRefNum any longer.  If you are using
the new Standard File routines, just use the fileSpec, or its component parts.

>This is necessary if you ever have to access a file which is given by
>a file-spec with old routines. However, if you are using the new FileSpec
>routines, you can just pass the FileSpec to them. If you are writing
>System-7 dependant stuff, I recommend this because you do not have to deal
>with the Poor Man's Search Path. But that doesn't make a difference with
>StandardPutFile/GetFile.

You _NEVER_ _EVER_ have to build a working directory.*  If you need to use
the information from a fileSpec when the fileSpec-based File manager calls
are not available, simply pass the component parts (vRefnum, directoryID,
name) to routines like _HOpen, _HCreate, _HCreateResFile, etc.



* -- Actually, you do if you're going to launch an application yourself
under a pre-System 7 OS.  But that's pretty rare, and is the _ONLY_
exception.

--
John Cavallino                  |  EMail: [e-mail]
University of Chicago Hospitals |         [e-mail]
Office of Facilities Management | USMail: 5841 S. Maryland Ave, MC 0953
B0 f++ c+ g+ k s+(+) e+ h- pv   |         Chicago, IL  60637



- -------------------------

From: [e-mail] (Keith Rollin)
Subject:  StandardPutFile
Date: 9 Feb 92 01:17:22 GMT
Organization: Apple Computer Inc., Cupertino, CA

In article <gtall.697477270@ogre> [e-mail] (Gerry Allwein) writes:
>I've been attempting to StandardPutFile and find that it the vRefNum field
>of the sfFile for the reply is always set to -1, not at all what the old
>SFPPutFile returns for the vRefNum. This is system 7.0, on a Mac ci. Anyone
>know how to fix this? Is it a bug in StandardPutFile?

There's nothing to fix, and there is no bug. If you'd just used the
value returned to you instead of trying to interpret it, you'd probably
have found that it worked just fine.

You're probably confused because for the first time in your life,
Standard File is actually returning a vRefNum in the vRefNum field.
Previous versions of Standard File were forced to return a working
directory ID because there was no other way to return a DirID. Now that
there is a DirID field in the new Standard File calls, there is no
reason to return a working directory ID. -1 is the vRefNum for the boot
volume, and is a perfectly fine value. (If you have Macsbug, drop into
it and execute the "vol" dcmd to see what I mean.) I'll bet that if
you'd tried to use it, it would have worked like a champ. Unless, of
course, you are getting -1 when selecting other volumes, in which
"something odd is happening."

Try using SFPPutFile to create a file at the root level of your boot
volume. You should receive a -1 as the vRefNum there, too.

Please refer to the File Manager chapter of IM IV for a description
of working directory numbers, and the Standard File chapters of IM's
I, IV, and VI for a description of what Standard File returns.

--
- ----------------------------------------------------------------------------
Keith Rollin           ---            <Taligent .signature under construction>
Disclaimer: Pretty soon, I really _won't_ be speaking for Apple...



- -------------------------

From: [e-mail] (Daniel Norman Johnson)
Subject:  about working directories (was Re: StandardPutFile)
Date: 9 Feb 92 02:33:14 GMT
Organization: Information Technology Services, Rennselaer Polytechnic Institute.

In article <[e-mail]>, [e-mail] (JohnC) writes:
|> In article <[e-mail]> [e-mail] writes:
|> >The vRefNum you get from StandardPutFile and StandardGetFile is *REALLY*
|> >a volume reference number, *NOT* a working directory reference number.

    [ and so on until... ]

|> NoNoNoNo.  Working directories are a compatibility hack for applications
|> that don't know about HFS and directory IDs.  You never have to make your
|> own.  When using the old Standard File routines, simply pass the contents
|> of the vRefNum field in the reply record to _GetWDInfo.  This routine will
|> return the corresponding _real_ volume refNum and a directoryID.  Once you
|> have these, you need not consider the wdRefNum any longer.  If you are using
|> the new Standard File routines, just use the fileSpec, or its component parts.

    [ and there's more, but this is what I wanted to comment on ]

I assure you, this particular hack is not going anywhere. If apple removes
it, every application that uses SFGetFile will break. It does mean
using 1 less variable, however, and I don't see any reason why the system
can't keep track of something for me.

The only reason I can think of for not using them is that it is possible that
Apple will change the format of the File Spec record (I doubt it myself),
and if that happens only using the real FSp-whatever routines will save you.

Of course, this is just a matter of personal taste. If you like directory
IDs, use 'em. But this JohnC whose message Im responding to make Working
Directories sound so very Evil that I thot I should say something.

On the other hand, I must admit I had (blush) forgotten about those H-whatever
routines, as I do not use them very often. The technique John tells of would work
too, you don't have to use Working Diretories (as I thot you did).

                - an embarrased Mac Programmer



- -------------------------

From: [e-mail] (Gerry Allwein)
Subject:  StandardPutFile
Date: 9 Feb 92 14:19:34 GMT
Organization: Center for Innovative Computing Applications (CICA), Indiana University

In <[e-mail]> [e-mail] (Keith Rollin) writes:

>In article <gtall.697477270@ogre> [e-mail] (Gerry Allwein) writes:
>>I've been attempting to StandardPutFile and find that it the vRefNum field
>>of the sfFile for the reply is always set to -1, not at all what the old
>>SFPPutFile returns for the vRefNum. This is system 7.0, on a Mac ci. Anyone
>>know how to fix this? Is it a bug in StandardPutFile?

>There's nothing to fix, and there is no bug. If you'd just used the
>value returned to you instead of trying to interpret it, you'd probably
>have found that it worked just fine.

>You're probably confused because for the first time in your life,
>Standard File is actually returning a vRefNum in the vRefNum field.
>Previous versions of Standard File were forced to return a working
>directory ID because there was no other way to return a DirID. Now that
>there is a DirID field in the new Standard File calls, there is no
>reason to return a working directory ID. -1 is the vRefNum for the boot
>volume, and is a perfectly fine value. (If you have Macsbug, drop into
>it and execute the "vol" dcmd to see what I mean.) I'll bet that if
>you'd tried to use it, it would have worked like a champ. Unless, of
>course, you are getting -1 when selecting other volumes, in which
>"something odd is happening."

>Try using SFPPutFile to create a file at the root level of your boot
>volume. You should receive a -1 as the vRefNum there, too.

>Please refer to the File Manager chapter of IM IV for a description
>of working directory numbers, and the Standard File chapters of IM's
>I, IV, and VI for a description of what Standard File returns.

That would be, "for the first time in your (Keith Rollin's) life", thank you!

Yes, I found the problem. Unfortunately for you, MacApp 2.0.1 and MacApp2.0
rely on working directories. I know, that is how I found the problem. And this
is a BUG because it isn't documented that there is variance with respect to
the documentation IM1,4,6. I call that bug, you can call it anything you like.

Gerry



- -------------------------

From: [e-mail] (Daniel Norman Johnson)
Subject:  StandardPutFile
Date: 9 Feb 92 15:44:30 GMT
Organization: Information Technology Services, Rennselaer Polytechnic Institute.

In article <gtall.697645174@ogre>, [e-mail] (Gerry Allwein) writes:
|> In <[e-mail]> [e-mail] (Keith Rollin) writes:
|>
|> >In article <gtall.697477270@ogre> [e-mail] (Gerry Allwein) writes:
|> >>I've been attempting to StandardPutFile and find that it the vRefNum field
|> >>of the sfFile for the reply is always set to -1, not at all what the old
|> >>SFPPutFile returns for the vRefNum. This is system 7.0, on a Mac ci. Anyone
|> >>know how to fix this? Is it a bug in StandardPutFile?
|>
|> >There's nothing to fix, and there is no bug. If you'd just used the
|> >value returned to you instead of trying to interpret it, you'd probably
|> >have found that it worked just fine.
|>
|> >You're probably confused because for the first time in your life,
|> >Standard File is actually returning a vRefNum in the vRefNum field.
|> >Previous versions of Standard File were forced to return a working
|> >directory ID because there was no other way to return a DirID. Now that
|> >there is a DirID field in the new Standard File calls, there is no
|> >reason to return a working directory ID. -1 is the vRefNum for the boot
|> >volume, and is a perfectly fine value. (If you have Macsbug, drop into
|> >it and execute the "vol" dcmd to see what I mean.) I'll bet that if
|> >you'd tried to use it, it would have worked like a champ. Unless, of
|> >course, you are getting -1 when selecting other volumes, in which
|> >"something odd is happening."
|>
|> >Try using SFPPutFile to create a file at the root level of your boot
|> >volume. You should receive a -1 as the vRefNum there, too.
|>
|> >Please refer to the File Manager chapter of IM IV for a description
|> >of working directory numbers, and the Standard File chapters of IM's
|> >I, IV, and VI for a description of what Standard File returns.
|>
|> That would be, "for the first time in your (Keith Rollin's) life", thank you!
|>
|> Yes, I found the problem. Unfortunately for you, MacApp 2.0.1 and MacApp2.0
|> rely on working directories. I know, that is how I found the problem. And this
|> is a BUG because it isn't documented that there is variance with respect to
|> the documentation IM1,4,6. I call that bug, you can call it anything you like.
|>
|> Gerry

Actually, it isn't a bug. What you are officialy supposed to do is pass
the sfFile (an FSSpec) to one of the FSp* routines, and that works just dandy.

I do think Apple should have document the difference, but it was really supposed
to be there.

What --->is<--- is bug is what happens if you follow my instructions however.
I said that OpenWD() should be called with a PBProcID field of 0, and this
is WRONG. I thot PBProcID was for your applications use, but it isn't. Its
the way the system knows who owns any particular Working Directory. Pass
your applications signature.

Passing 0 works, but it means that you would be SHARING Working directories
with any other app that also passes 0, which is bad. But then, that's
what you get for listening to me. :)

Well, I'll just crawl off into a corner in hide now, as I've spread as much
misinformation as I can for 1 weekend...



- -------------------------

From: [e-mail] (JohnC)
Subject:  about working directories (was Re: StandardPutFile)
Date: 9 Feb 92 18:45:45 GMT
Organization: The Royal Society for Putting Things on Top of Other Things

In article <_=ds![e-mail]> [e-mail] writes:
>I assure you, this particular hack is not going anywhere. If apple removes
>it, every application that uses SFGetFile will break. It does mean
>using 1 less variable, however, and I don't see any reason why the system
>can't keep track of something for me.

Ah, but it is, via the directory ID.  If you don't like piles of variables,
just use fileSpecs all the time (one variable) and fill in their fields
yourself if System 7 is not available.

>The only reason I can think of for not using them is that it is possible that
>Apple will change the format of the File Spec record (I doubt it myself),
>and if that happens only using the real FSp-whatever routines will save you.
>
>Of course, this is just a matter of personal taste. If you like directory
>IDs, use 'em. But this JohnC whose message Im responding to make Working
>Directories sound so very Evil that I thot I should say something.

Hey, "evil" is most certainly an exaggeration. ;-)  I agree that working
directories aren't going away soon, if ever, but I maintain that they should
never be used by code that wasn't written by Apple Blue Meanies.  One major
disadvantage is that there is a fixed maximum number of working directories
for all applications on the machine, and thought I'm sure the system tries
to be clever at deallocating them as soon as they are no longer needed, one
could run out if one opens many files from different folders.  Another problem
is that as long as a working directory exists for a folder, when you try to
throw away that folder, the Finder will complain that the item is "in use" or
contains items that are "in use".  I'm sure this is very confusing for
novices, and is the main reason I don't use working directories.


--
John Cavallino                  |  EMail: [e-mail]
University of Chicago Hospitals |         [e-mail]
Office of Facilities Management | USMail: 5841 S. Maryland Ave, MC 0953
B0 f++ c+ g+ k s+(+) e+ h- pv   |         Chicago, IL  60637



- -------------------------

From: [e-mail] (JohnC)
Subject:  StandardPutFile
Date: 9 Feb 92 18:49:46 GMT
Organization: The Royal Society for Putting Things on Top of Other Things

In article <6xds##[e-mail]> [e-mail] writes:
>What --->is<--- is bug is what happens if you follow my instructions however.
>I said that OpenWD() should be called with a PBProcID field of 0, and this
>is WRONG. I thot PBProcID was for your applications use, but it isn't. Its
>the way the system knows who owns any particular Working Directory. Pass
>your applications signature.
>
>Passing 0 works, but it means that you would be SHARING Working directories
>with any other app that also passes 0, which is bad. But then, that's
>what you get for listening to me. :)

Actually, under Multifinder/Process Manager, the procID is ignored by the
system.  Instead, it tags the working directory with a value uniquely
identifying the process that created it, to facilitate automatic
deallocation when the process terminates.

--
John Cavallino                  |  EMail: [e-mail]
University of Chicago Hospitals |         [e-mail]
Office of Facilities Management | USMail: 5841 S. Maryland Ave, MC 0953
B0 f++ c+ g+ k s+(+) e+ h- pv   |         Chicago, IL  60637



- -------------------------

From: [e-mail] (Kent Sandvik)
Subject:  StandardPutFile
Date: 10 Feb 92 05:00:23 GMT
Organization: MacDTS Mongols

In article <gtall.697645174@ogre>, [e-mail] (Gerry Allwein) writes:
> Yes, I found the problem. Unfortunately for you, MacApp 2.0.1 and MacApp2.0
> rely on working directories. I know, that is how I found the problem. And this
> is a BUG because it isn't documented that there is variance with respect to
> the documentation IM1,4,6. I call that bug, you can call it anything you like.

MacApp 3.0 tries to use FSSpecs if possible, see sample below:

pascal OSErr TFile::CreateRsrcFork()
{
    if (qNeedsAliasMgr || gConfiguration.hasAliasMgr)
    {
        FSSpec theFile = fFileSpec;

        FSpCreateResFile(theFile, fCreator, fFileType, fScriptTag);
    }
    else
    {
        CStr63 fileName = fFileSpec.name;

        HCreateResFile(fFileSpec.vRefNum, fFileSpec.parID, fileName);

        if (ResError() == noErr)
        {
            HParamBlockRec pb;

            GetFileInfo(pb);
            pb.fileParam.ioFlFndrInfo.fdCreator = fCreator;
            pb.fileParam.ioFlFndrInfo.fdType = fFileType;
            SetFileInfo(pb);
        }
    }
    return ResError();
}

Kent Sandvik/DTS



- -------------------------

From: [e-mail] (Milton Sagen)
Subject:  StandardPutFile
Date: 10 Feb 92 07:12:47 GMT
Organization: TECHbooks of Beaverton Oregon - Public Access Unix

In article <[e-mail]> [e-mail] writes:
>
>I know, they are always called vRefNums. Usually they do not mean it. What
>you need to do is use the OpenWD (open working directory) command System 7.0
>provides to make that into a Working Directory Refnum; Do not worry about

Why?  The FSSpec record not only gives you the vRefNum but also the dirID of
the parent directory so why not use those file manager calls which use a
true vRefNum and dirID?

>the fact that this command is not availiable in system 6.0, because FileSpecs
>and such things don't even happen. So just use OpenWD and don't use PBOpenWD (

Hasn't Apple been suggesting not to open working directories?  It seems to me
one of the Tech Notes suggested against it.

>You'll need to use the parent directory id for this also.
>
>For that other parameter (PBprocID or something like that?) just pass 0;
>that way if you need to access the same working directory more than once it'll
>just give you the same Working Directory. I don't know if you are supposed
>to close the WD, does anybody here?

If you don't have to open it then you don't have to worry about whether to
close it or not.
--
Milton E. Sagen                          [e-mail]
Software Engineer                        !{tektronix!nosun,uunet}techbook!sagen
Prometheus Products, Inc.                [phone] (voice)
Tualatin, OR 97062                       [phone] (fax)



- -------------------------

From: [e-mail] (Matthew T. Russotto)
Subject:  StandardPutFile
Date: 10 Feb 92 15:21:47 GMT
Organization: University of Maryland, College Park, College of Engineering

In article <[e-mail]> [e-mail] writes:
>> I've been attempting to StandardPutFile and find that it the vRefNum field
>> of the sfFile for the reply is always set to -1, not at all what the old
>> SFPPutFile returns for the vRefNum. This is system 7.0, on a Mac ci. Anyone
>> know how to fix this? Is it a bug in StandardPutFile?
>
>> Gerry
>
>Yes, I just had to figure that out. Its really supposed to do that.
>
>The vRefNum you get from StandardPutFile and StandardGetFile is *REALLY*
>a volume reference number, *NOT* a working directory reference number.
>(read Inside Macintosh Volume 4 for what a Working Directory is, if you
>do not know)
>
>I know, they are always called vRefNums. Usually they do not mean it. What
>you need to do is use the OpenWD (open working directory) command System 7.0
...
>You'll need to use the parent directory id for this also.
...
>This is necessary if you ever have to access a file which is given by
>a file-spec with old routines. However, if you are using the new FileSpec

Huh?  No it isn't-- since the Mac Plus, the routines for accessing a file
given the directory ID, real volume reference number, and partial
pathname have existed-- i.e.
PBHOpen
PBHGetFInfo
PBHDelete
....
Newer development systems even have high-level glue for these routines.
--
Matthew T. Russotto    [e-mail]    [e-mail]
Your superior intellect is no match for our puny weapons! -- The Simpsons
Just say NO to police searches and seizures.  Make them use force.
(not responsible for bodily harm resulting from following above advice)



- -------------------------

From: [e-mail] (Steve Dorner)
Subject:  about working directories (was Re: StandardPutFile)
Organization: University of Illinois at Urbana-Champaign
Date: Mon, 10 Feb 1992 21:19:47 GMT

[e-mail] writes:
>Hey, "evil" is most certainly an exaggeration. ;-)  I agree that working
>directories aren't going away soon, if ever, but I maintain that they should
>never be used by code that wasn't written by Apple Blue Meanies.

My $.02:

There's no harm in using Working directories that you get from standard file
or the Finder; as people have said, these aren't going away soon.
Furthermore the OS manages them, which takes away one of the big problems.

I think the real stricture lies in CREATING the darn things.  If your
program is going to call OpenWD, think twice and three times.  It's
really very unpleasant, because you'll never know when you can or can't
get rid of them.  You'll either run out (someday), or you'll end up
disposing one that standard file or somebody else was looking at, with
bad consequences.
--
Steve Dorner, U of Illinois Computing Services Office
(He who has done nothing for UIUC students, except harass them.)
Internet: [e-mail]  UUCP: uunet!uiucuxc!uiuc.edu!s-dorner



- -------------------------

From: [e-mail] (Tim Dierks, ToyMeister, Cray abuser)
Subject:  about working directories (was Re: StandardPutFile)
Date: 10 Feb 92 22:36:14 GMT
Organization: MacDTS, Apple Computer

In article <_=ds![e-mail]>, [e-mail] (Daniel Norman Johnson) writes:
>
> In article <[e-mail]>, [e-mail] (JohnC) writes:
> |> In article <[e-mail]> [e-mail] writes:
> |> >The vRefNum you get from StandardPutFile and StandardGetFile is *REALLY*
> |> >a volume reference number, *NOT* a working directory reference number.
>
>     [ and so on until... ]
>
> |> NoNoNoNo.  Working directories are a compatibility hack for applications
> |> that don't know about HFS and directory IDs.  You never have to make your
> |> own.  When using the old Standard File routines, simply pass the contents
> |> of the vRefNum field in the reply record to _GetWDInfo.  This routine will
> |> return the corresponding _real_ volume refNum and a directoryID.  Once you
> |> have these, you need not consider the wdRefNum any longer.  If you are using
> |> the new Standard File routines, just use the fileSpec, or its component parts.
>
>     [ and there's more, but this is what I wanted to comment on ]
>
> I assure you, this particular hack is not going anywhere. If apple removes
> it, every application that uses SFGetFile will break. It does mean
> using 1 less variable, however, and I don't see any reason why the system
> can't keep track of something for me.

In this case, there's a couple of good reasons not to have the System keeping
track of this for you.  First, the system doesn't have any way to tell what
directory records you're using and which you're not.  If I open and close
500 files in your application, should the system maintain 500 different
working directories for the locations of each of these files?  How can it
be sure that your program will never need to look at any of these files
again?  Obviously, it's going to need to deallocate some of the records at
some point.  If you go back and try to use that working directory again,
Bad Things will happen.  Secondly, you're abstracting yourself from the
actual structure of the file system and from the approved format for these
values.  This means that if you need to index into a sub-directory, you'll
actually have to create a working directory to get the single, 16-bit
number the rest of your code expects.  Furthermore, if you want to use
alias records, etc, you'll have to resolve the working directory to build
the FSSpec you need.  It seems like a lot of useless work to convert back
and forth, back and forth.  Why not just use an FSSpec?  It's also just
one variable, only it's a little bigger than a vRefNum + filename (which is
2 variables!)

Support for working directories may not be forever.  It's hard to say at
this point, but you should avoid using working directories if at all
possible.

Tim Dierks
MacDTS, but I speak for myself



- -------------------------

From: [e-mail] (Matthias Ulrich Neeracher)
Subject:  about working directories (was Re: StandardPutFile)
Date: 11 Feb 92 16:53:24 GMT
Organization: Integrated Systems Laboratory, ETH, Zurich

In article <[e-mail]> [e-mail] (Tim Dierks, ToyMeister, Cray abuser) writes:
>In article <_=ds![e-mail]>, [e-mail] (Daniel Norman Johnson) writes:
>In this case, there's a couple of good reasons not to have the System keeping
>track of this for you.
>[Lots of good reasons not to use WDs deleted]
>Support for working directories may not be forever.  It's hard to say at
>this point, but you should avoid using working directories if at all
>possible.

The reason why I use working directories in some of my applications is that I
need ways to set the default directory, and HSetVol will break at the moment
someone else decides to call GetVol/SetVol. So, I see no alternative to using
working directories.

Matthias

- ---
Matthias Neeracher                                   [e-mail]
  "... Rice walked out wondering if the world was nothing but wimps,
   pimps, psychos and sex fiends" -- James Ellroy, _Suicide Hill_



- -------------------------

From: [e-mail] (Daniel Norman Johnson)
Subject:  about working directories (was Re: StandardPutFile)
Organization: Information Technology Services, Rennselaer Polytechnic Institute.
Date: Tue, 11 Feb 1992 19:47:42 GMT

In article <[e-mail]>, [e-mail] (JohnC) writes:
|> >  [ various things until ] . It does mean
|> >using 1 less variable, however, and I don't see any reason why the system
|> >can't keep track of something for me.
|>
|> Ah, but it is, via the directory ID.  If you don't like piles of variables,
|> just use fileSpecs all the time (one variable) and fill in their fields
|> yourself if System 7 is not available.
|>

So I can keep track of 3 fields instead of 2. Hmmmmm... Of course under system
7 the system will take care of it for me, and I will (honest honest) use them
when I write Sys-7 dependant stuff. But I get to write the FSp routines if
it doesn't. Sounds like I get to keep track of 'em.

|> >The only reason I can think of for not using them is that it is possible that
|> >Apple will change the format of the File Spec record (I doubt it myself),
|> >and if that happens only using the real FSp-whatever routines will save you.
|> >
|> >Of course, this is just a matter of personal taste. If you like directory
|> >IDs, use 'em. But this JohnC whose message Im responding to make Working
|> >Directories sound so very Evil that I thot I should say something.
|>
|> Hey, "evil" is most certainly an exaggeration. ;-)  I agree that working
|> directories aren't going away soon, if ever, but I maintain that they should
|> never be used by code that wasn't written by Apple Blue Meanies.  One major
|> disadvantage is that there is a fixed maximum number of working directories
|> for all applications on the machine, and thought I'm sure the system tries
|> to be clever at deallocating them as soon as they are no longer needed, one
|> could run out if one opens many files from different folders.

I expect that is true, but under system 7 I have been able to allocate
84384 of them, all with different PBProcIDs. (that number is vague in my memory,
but it is 5 digits long and starts with an 8. Im sure of that). If thats not
enough, I stopped it htere, I didn't let it go on until it ran out (Im too lazy);
and as far as I know the system had no way of knowing that I was not going to
use 'em. How could the system know that I had no more plans to use a
particular WD that I allocated myself (or even one that it gave me?)

Of course, System 6, 5, 4, etc may not be so nice but then I'm not advocating
allocating yer own WDs for them. I see no reason to bother, SFGetFile always
give you one (and I very much expect it does not give you duplicates, although
I am not sure, so that overloading things that way would take a lot of double-
clicking)

!> Another problem
|> is that as long as a working directory exists for a folder, when you try to
|> throw away that folder, the Finder will complain that the item is "in use" or
|> contains items that are "in use".  I'm sure this is very confusing for
|> novices, and is the main reason I don't use working directories.
|>

I did not know ->that<-. But it is very easy to fix. It requries very
little care, because there is only one routine in my program anyway that can
destroy a document, so I'll use that to check for any other documents that use
the same WD and if none are found I'll close it. That doesn't sound hard.

But if there are any other little traps waiting to screw me up like that, I'd
appreciate if you would bring them up. A few more little (but nasty) things
like that last one, and I'll have to admit their problem outweigh their
advantages.



- -------------------------

From: [e-mail] (Daniel Norman Johnson)
Subject:  about working directories (was Re: StandardPutFile)
Organization: Information Technology Services, Rennselaer Polytechnic Institute.
Date: Tue, 11 Feb 1992 21:12:07 GMT

In article <[e-mail]>, [e-mail] (Tim Dierks, ToyMeister, Cray abuser) writes:
|> In article <_=ds![e-mail]>, [e-mail] (Daniel Norman Johnson) writes:
|> >
|> > In article <[e-mail]>, [e-mail] (JohnC) writes:
|> > |> In article <[e-mail]> [e-mail] writes:
|> > |> >The vRefNum you get from StandardPutFile and StandardGetFile is *REALLY*
|> > |> >a volume reference number, *NOT* a working directory reference number.
|> >
|> >     [ and so on until... ]
|> >
|> > |> NoNoNoNo.  Working directories are a compatibility hack for applications
|> > |> that don't know about HFS and directory IDs.  You never have to make your
|> > |> own.  When using the old Standard File routines, simply pass the contents
|> > |> of the vRefNum field in the reply record to _GetWDInfo.  This routine will
|> > |> return the corresponding _real_ volume refNum and a directoryID.  Once you
|> > |> have these, you need not consider the wdRefNum any longer.  If you are using
|> > |> the new Standard File routines, just use the fileSpec, or its component parts.
|> >
|> >     [ and there's more, but this is what I wanted to comment on ]
|> >
|> > I assure you, this particular hack is not going anywhere. If apple removes
|> > it, every application that uses SFGetFile will break. It does mean
|> > using 1 less variable, however, and I don't see any reason why the system
|> > can't keep track of something for me.
|>
|> In this case, there's a couple of good reasons not to have the System keeping
|> track of this for you.  First, the system doesn't have any way to tell what
|> directory records you're using and which you're not.  If I open and close
|> 500 files in your application, should the system maintain 500 different
|> working directories for the locations of each of these files?  How can it
|> be sure that your program will never need to look at any of these files
|> again?  Obviously, it's going to need to deallocate some of the records at
|> some point.  If you go back and try to use that working directory again,
|> Bad Things will happen.

(boy, if we keep this up, we'll get ourselves a genuine flame war!) :)
I don't think you are going to do that, but if you do in *my* app, you're
covered because the working directory for each doc is stored in its record
(along with various thigns like a handle to the document data); this record
hangs off a handle in the refCon of the window record. So, when I close (for
any reason) a document, its easy to tell if I should close the WD. I'm am going
to do this (haven't yet) because of the revelation I got from JohnC that the
system will not let anyone destroy dirs that have WDs to them.

That is a real concern to me (I hope there are no more like it) but you must
realize that to allocate 500 WDs you must open 500 files in different
directories. If you want to do this simultaneously, you must have memory for them
all. Do you think this will happen? More relevantly, will it be usefull? I can
say the answer is no for any app that I have ever written, but if it is
yes for yours, by all means use some other technology for your app.

!>  Secondly, you're abstracting yourself from the
|> actual structure of the file system and from the approved format for these
|> values.  This means that if you need to index into a sub-directory, you'll
|> actually have to create a working directory to get the single, 16-bit
|> number the rest of your code expects.  Furthermore, if you want to use
|> alias records, etc, you'll have to resolve the working directory to build
|> the FSSpec you need.  It seems like a lot of useless work to convert back
|> and forth, back and forth.  Why not just use an FSSpec?  It's also just
|> one variable, only it's a little bigger than a vRefNum + filename (which is
|> 2 variables!)
|>
|> Support for working directories may not be forever.  It's hard to say at
|> this point, but you should avoid using working directories if at all
|> possible.

This all started when I suggested using WD to decode File-Specs under
system-7 (yes, I know that has risks of its own, but this discussion has
so for proceeded assuming that that is what we want to do), so that you can
use StandardPutFile like SFPutFile. If your app creats a -folder- when
you do a SFPutFile, I think maybe you need to think about your design a bit.
StandardPutFile takes care of aliases for you, before it returns.
Of course, I would much prefer to use FSSpecs. I will, if I ever write something
system-7 dependant. However it is just additional complication before then.

How can working directories be removed without toasting every app that uses
SFGetFile and SFPutFile? I really don't see how this can be done (or why
it would) I suppose Apple could make it so OpenWD/PBOpenWD/etc is not
available to anything but the system. I think Apple would be very silly to do
this. It also seems odd that apple should add a new high-level equivalent to
the OS for this (OpenWD may be glued, but it is not in the OS until Sys-7.0,
according to IM-VI), and then remove the whole routine although maybe thats
just beaurocrasy for ya.

I wouldn't use WD for everything. They have shortcomings, and they have more
surprises then I thot they would. But they simplify things a bit, in some
cases. They seem easy enough to deal with to me, but that is partly because
of the way my applications are put together inside. So maybe something else
would work better for you. And there's no law that says you have to use
only one technique per app, unless I am very much mistaken. (tho it makes
things simpler)

It seems to me that this discussion is being to wind back on itself, and
cover things that we have already covered. I wonder if that is worth the
bandwidth. I certainly do NOT want to wind up having to defend the position
that WDs are the end-all and be-all of the MacOS file system.
I was just offering a solution for --->one<--- (count em) problem, not trying
to dictate how all file access is to be done. My solution does in fact solve
the problem, and it did before I presented it. (it will work better now that
I am better informed about some of the problems with WDs, tho)

There are lots of reasons you might not want to do it that way. The best I know
of is that it may not be convinient for you. But please don't complain
that the solution I proposed isn't adequate for solving some other, completely
disconnected problem. That's silly. unless of course *my* posts were implying
that WDs were For All Things. If so (I hope its not), I apologize. Honestly,
this is not the point I wished to get across, and I do not believe it myself.

But let me just make it clear what the problem was, and what I proposed.
The problem was that if you try to use the .sfFile.vRefNum field that
is returned in the reply to a StandardPutFile, it doesn't work (and is itself
-1, in this case tho that did not turn out to matter); I proposed that the
victim of this problem could use OpenWD to convert the .vRefNum and .parID
fields into a working directory and use that. I did mention the file-spec
routines, but they are not appropriate because they are system-7 only,
or I understand they are. (If they are not, somebody tell me, because I would
really rather use File-Specs. If its a matter of Glue, I use ThinkC 5.0 but
I have not seen any reference to them in the docs!)

I (oops) forgot about the H... routines. :( They would work, I just forgot.
I have already apologized, and I don't think it is all THAT bad, as after
all several (ok 2) people have since mentioned them.

Now don't be put off, I just don't want to defend a position I dont buy
into myself! I do still want to hear about the wierd and wonderfull nature
of Working Directories (particularly pitfalls, as I have already picked up
one valuable item that I did not know) and particularly, if Apple has plans
to change the FSSpec record (I have a feeling Murphy is going to Get Me that
way, And Ill have to use FSp* anyway.)

I just want to make it clear what I was saying. I looks (to me) like I must
not have been clear enough about it, and wound up arguing something I didn't
mean.



- -------------------------

From: [e-mail] (JohnC)
Subject:  about working directories (was Re: StandardPutFile)
Organization: The Royal Society for Putting Things on Top of Other Things
Date: Tue, 11 Feb 1992 20:40:02 GMT

In article <[e-mail]> [e-mail] writes:
>So I can keep track of 3 fields instead of 2. Hmmmmm... Of course under system
>7 the system will take care of it for me, and I will (honest honest) use them
>when I write Sys-7 dependant stuff. But I get to write the FSp routines if
>it doesn't. Sounds like I get to keep track of 'em.

<sigh>  Here is are two code fragments:

{method A}
VAR    theName:Str255;
    theVolume:integer;
    theRefnum:integer;
    err:OSErr;

    err:=FSOpen(theName,theVolume,theRefnum);

{method B}
VAR    theSpec:FSSpec;
    theRefnum:integer;
    err:OSErr;

    err:=HOpen(theSpec.vRefNum,theSpec.dirID,theSpec.name,
               fsRdWrPerm,theRefnum);

Method A relies on working directories.  Method B does not, using the
fileSpec record in a way that is _not_ dependent upon System 7.  There are
no "FSp routines" to be written.

--
John Cavallino                  |  EMail: [e-mail]
University of Chicago Hospitals |         [e-mail]
Office of Facilities Management | USMail: 5841 S. Maryland Ave, MC 0953
B0 f++ c+ g+ k s+(+) e+ h- pv   |         Chicago, IL  60637



- -------------------------

From: [e-mail] (JohnC)
Subject:  about working directories (was Re: StandardPutFile)
Date: 11 Feb 92 21:54:53 GMT
Organization: The Royal Society for Putting Things on Top of Other Things

In article <[e-mail]> [e-mail] writes:
>But let me just make it clear what the problem was, and what I proposed.
>The problem was that if you try to use the .sfFile.vRefNum field that
>is returned in the reply to a StandardPutFile, it doesn't work (and is itself
>-1, in this case tho that did not turn out to matter); I proposed that the
>victim of this problem could use OpenWD to convert the .vRefNum and .parID
>fields into a working directory and use that. I did mention the file-spec
>routines, but they are not appropriate because they are system-7 only,
>or I understand they are. (If they are not, somebody tell me, because I would
>really rather use File-Specs. If its a matter of Glue, I use ThinkC 5.0 but
>I have not seen any reference to them in the docs!)
>
>I (oops) forgot about the H... routines. :( They would work, I just forgot.
>I have already apologized, and I don't think it is all THAT bad, as after
>all several (ok 2) people have since mentioned them.

The problem is how to use FileSpecs without requiring the System 7 high-level
file manager calls.  The solution is the "H-routines" that you forgot about.
It is _not_ necessary to open working directories.

--
John Cavallino                  |  EMail: [e-mail]
University of Chicago Hospitals |         [e-mail]
Office of Facilities Management | USMail: 5841 S. Maryland Ave, MC 0953
B0 f++ c+ g+ k s+(+) e+ h- pv   |         Chicago, IL  60637



- -------------------------

From: [e-mail] (Daniel Norman Johnson)
Subject:  about working directories (was Re: StandardPutFile)
Organization: Information Technology Services, Rennselaer Polytechnic Institute.
Date: Wed, 12 Feb 1992 20:38:54 GMT

In article <[e-mail]>, [e-mail] (JohnC) writes:
|>
|> The problem is how to use FileSpecs without requiring the System 7 high-level
|> file manager calls.  The solution is the "H-routines" that you forgot about.
|> It is _not_ necessary to open working directories.
|>

Is it? Well, if you like. This discussion certainly applies to that in any
case. I was not thinking in terms of a general case particularly when
I suggested Working Directories.

H... routines are a solution. If you are saying the WD are not a solution,
well, if you say so. I find that difficult to buy. (if you had not noticed);

But to each his own.

By the way, I believe you asked at some point (I've lost track!) what was
going on with my test. I had assumed that ProcIDs were not being ignored. So
what I was really doing was allocating the same WD 8 zillion times. Not very
usefull, is it? At any rate 40 WDs will certainly do fine. (for me that is,
if its not good enough for you, don't use them)



- -------------------------

From: [e-mail] (Daniel Norman Johnson)
Subject:  StandardPutFile
Organization: Information Technology Services, Rennselaer Polytechnic Institute.
Date: Tue, 11 Feb 1992 19:56:05 GMT

In article <[e-mail]>, [e-mail] (JohnC) writes:
|> In article <6xds##[e-mail]> [e-mail] writes:
|> >What --->is<--- is bug is what happens if you follow my instructions however.
|> >I said that OpenWD() should be called with a PBProcID field of 0, and this
|> >is WRONG. I thot PBProcID was for your applications use, but it isn't. Its
|> >the way the system knows who owns any particular Working Directory. Pass
|> >your applications signature.
|> >
|> >Passing 0 works, but it means that you would be SHARING Working directories
|> >with any other app that also passes 0, which is bad. But then, that's
|> >what you get for listening to me. :)
|>
|> Actually, under Multifinder/Process Manager, the procID is ignored by the
|> system.  Instead, it tags the working directory with a value uniquely
|> identifying the process that created it, to facilitate automatic
|> deallocation when the process terminates.
|>

Really? Hmmmm. Where are you finding this stuff out? I do not remember IM-VI
saying anything about it (tho I could easily have missed it), but Im glad to know
the system is going to be mercifull. But it seems odd to me that IM-IV should
say that you must use your Applications Signature. What does this do, if
anything?

Also, Under Multifinder/Sys-7, does PBGetWDInfo index through -all- of the
Working Directories, or just yours?

<groan>, the worst part is that if the system just -ignores- the ProcID then
my tests (which assumed you can allocate lots and lots of WDs if you gave
them different proc-ids) are garbage. I'll have to write a new one, that
allocates different folders. bleah. All that wasted work (about 10 lines..) :<




- -------------------------

From: [e-mail] (JohnC)
Subject:  StandardPutFile
Organization: The Royal Society for Putting Things on Top of Other Things
Date: Tue, 11 Feb 1992 20:19:36 GMT

In article <g5gs4=[e-mail]> [e-mail] writes:
>|> Actually, under Multifinder/Process Manager, the procID is ignored by the
>|> system.  Instead, it tags the working directory with a value uniquely
>|> identifying the process that created it, to facilitate automatic
>|> deallocation when the process terminates.
>|>
>
>Really? Hmmmm. Where are you finding this stuff out? I do not remember IM-VI
>saying anything about it (tho I could easily have missed it), but Im glad to
>know the system is going to be mercifull. But it seems odd to me that IM-IV
>should say that you must use your Applications Signature. What does this do,
>if anything?

The stuff about Multifinder's handling of the procID was in one of the tech
notes about Multifinder, I believe.  Either that or the Programmer's Guide
to Multifinder.  The reason that IM-6 doesn't talk about it is that both
Multifinder and working directories are _obsolete_.  The discrepancy
between IM-4 and IM-6 that you mention is a symptom of a big problem with
Inside Macintosh, which is that certain parts of older volumes become
inaccurate as the Mac evolves, but there's no easy way to tell, except by
memorizing all six volumes.  (which I have done, ;-)

>Also, Under Multifinder/Sys-7, does PBGetWDInfo index through -all- of the
>Working Directories, or just yours?

I have no idea.

><groan>, the worst part is that if the system just -ignores- the ProcID then
>my tests (which assumed you can allocate lots and lots of WDs if you gave
>them different proc-ids) are garbage. I'll have to write a new one, that
>allocates different folders. bleah. All that wasted work (about 10 lines..) :<

There has always been a fixed limit of 40 working directories.  I'm nearly
certain that this limit still exists in System 7.  Could someone from Apple
comment?

--
John Cavallino                  |  EMail: [e-mail]
University of Chicago Hospitals |         [e-mail]
Office of Facilities Management | USMail: 5841 S. Maryland Ave, MC 0953
B0 f++ c+ g+ k s+(+) e+ h- pv   |         Chicago, IL  60637



- -------------------------

From: [e-mail] (Keith Rollin)
Subject:  about working directories (was Re: StandardPutFile)
Date: 14 Feb 92 02:34:26 GMT
Organization: Apple Computer Inc., Cupertino, CA

In article <[e-mail]> [e-mail] (Matthias Ulrich Neeracher) writes:
>
>The reason why I use working directories in some of my applications is that I
>need ways to set the default directory, and HSetVol will break at the moment
>someone else decides to call GetVol/SetVol. So, I see no alternative to using
>working directories.

I would argue with first, your premise, and second, your solution.

My initial feeling is that your applications do not need to set the
default directory. I've been programming the Mac for many years, and
have never needed to set the default directory. Many people think they
do, but it turns out that many times they are wrong. For instance,
many people look at the description for OpenResFile and feel that they
need to set the default directory, not realizing that there is an
HOpenResFile call. Others feel that they need to set the default
directory when porting a UNIX application to the Mac. This is probably
the most valid reason I've heard for setting the default directory, but
my position is still that the port should do things the Mac way and use
the native file system calls.

Just because _I've_ never needed to set the default directory doesn't
mean that you haven't. If you still feel that you need to set the
default directory, then I'd probably take an approach that didn't
require me to create a working directory ID. For instance, calling
HSetVol is perfectly OK, so long as you match it with calls to HGetVol
in your own code, and make sure that things like DA's running in your
application space (a rarity these days) aren't tripped up by it. If
this matters to you, simply make sure that you leave the default volume
set to something represented by a working directory just before calling
WaitNextEvent, and then restore it to what you want afterwards.

Remember, SetVol was brought to you by the same people who brought you
SetPt. It was merely a means to save a few bytes in applications that
had only 50K or so of heap to run around in. These savings mean very
little in these days of megabyte machines, so it's better to completely
use the "clean" solution of FSpXXX and HXXX calls.

--
- ----------------------------------------------------------------------------
Keith Rollin           ---            <Taligent .signature under construction>
Disclaimer: Pretty soon, I really _won't_ be speaking for Apple...



- -------------------------

From: [e-mail] (Matthias Ulrich Neeracher)
Subject:  about working directories (was Re: StandardPutFile)
Date: 14 Feb 92 09:42:01 GMT
Organization: Integrated Systems Laboratory, ETH, Zurich

In article <[e-mail]> [e-mail] (Keith Rollin) writes:
>In article <[e-mail]> [e-mail] (Matthias Ulrich Neeracher) writes:
>>
>>The reason why I use working directories in some of my applications is that I
>>need ways to set the default directory, and HSetVol will break at the moment
>>someone else decides to call GetVol/SetVol. So, I see no alternative to using
>>working directories.
>
>I would argue with first, your premise, and second, your solution.
>
>My initial feeling is that your applications do not need to set the
>default directory. I've been programming the Mac for many years, and
>have never needed to set the default directory.

OK, I agree, a normal application does not need to do this, but...

>Others feel that they need to set the default
>directory when porting a UNIX application to the Mac. This is probably
>the most valid reason I've heard for setting the default directory, but
>my position is still that the port should do things the Mac way and use
>the native file system calls.

This was exactly my problem. I was porting Perl to the Mac, and if some script
wants to call chdir(), I can't well refuse.

>If you still feel that you need to set the
>default directory, then I'd probably take an approach that didn't
>require me to create a working directory ID. For instance, calling
>HSetVol is perfectly OK, so long as you match it with calls to HGetVol
>in your own code, and make sure that things like DA's running in your
>application space (a rarity these days) aren't tripped up by it. If
>this matters to you, simply make sure that you leave the default volume
>set to something represented by a working directory just before calling
>WaitNextEvent, and then restore it to what you want afterwards.

I thought of doing something like this, but unfortunately, there is no list of
_Traps that might mess up your HSetVol_. WaitNextEvent is certainly one of
them, so is AESend if I wait for a reply. What about SFPutFile ? PrOpen ? Can I
rely on all Apple written code preserving my HSetVol, and not merely my SetVol ?

The other solution would be to bracket all calls to the standard C io library
with HSetVols. Not that attractive a prospect.

Matthias

- ---
Matthias Neeracher                                      [e-mail]
  "Nur die halbe Welt ist Teflon und Asbest" -- Einstuerzende Neubauten



- -------------------------

From: [e-mail] (Jon W{tte)
Subject:  about working directories (was Re: StandardPutFile)
Date: 14 Feb 92 17:43:18 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

.ch> [e-mail] (Matthias Ulrich Neeracher) writes:

   >Others feel that they need to set the default
   >directory when porting a UNIX application to the Mac. This is probably
   >the most valid reason I've heard for setting the default directory, but
   >my position is still that the port should do things the Mac way and use
   >the native file system calls.

   This was exactly my problem. I was porting Perl to the Mac, and if some
   script wants to call chdir(), I can't well refuse.

I've found that an easier approach is to write your _own_ stdio library,
as well as underlying unixio library. Your own library can have variables
for which directory is considered the "default" and push that vRefNum/dirID
pair into the calls it makes. Thus you do not have to use SetVol at all,
since your own library does the only proper thing and uses the HFileCall
calls.

   rely on all Apple written code preserving my HSetVol, and not merely my
   SetVol ?

HSetVol is dangerous. Don't use it. And when you do, set it back right
afterwards.

You could probably hack the Think libraries to support that feature,
since you have the sources. Just don't distribute the modified source !

--
This Signature is distributed under the conditions of the Signature License,
available at a fee from   [e-mail]  (Jon W{tte)  Reading the Signature
implies that you accept to be bound by the terms in said License. Should you
not agree on any of these terms, you must return the Signature unread to me.



---------------------------

End of C.S.M.P. Digest
**********************